home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄23⁄90 / 0698-Persistence and Meta-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-23  |  3.6 KB  |  72 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    8918850                         16-Feb-90        23:18PST
  4.  
  5. From:   D4384                           US Voting Mach, Sarner, Calvin,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Persistence and Metadata
  10.  
  11. I am just back in town, and find my mailbox full of persistence and metadata
  12. discussion. So here's my reactions:
  13.  
  14. James,
  15.     I agree that TDocument is sometimes more trouble than it is worth. If Apple
  16. solves all our problems with its next incarnation I would be thrilled, but I'm
  17. not holding my breath. In the meantime, I have work to do.
  18.     Yes, databases are wily dragons, and I have tricked a few into submission
  19. myself (though grudging submission at best, dragons being dragons). I have been
  20. nearly drowning in the OOPS/OODBMS literature for a few years now, and agree it
  21. would be unwise for us as guerillas to attempt to solve the object oriented
  22. database problem in all its generality (if I could do it that easily I'd be
  23. looking for venture capital). But products like ONTOS and Inside/Out are big,
  24. expensive, and far more powerful than needed for many purposes, and the very
  25. general models of data that they enforce can be inappropriate to many more
  26. specialized needs.
  27.     Both Larry and I, and I suspect many others, have independently solved
  28. various problems, some suprisingly subtle, relating to common problems like
  29. "how do I get data objects in and out of documents without reinventing the
  30. wheel or leasing a Cadillac" and "how do I load my customers' 5 megabyte
  31. document into 256K of RAM without making them wait for virtual memory, which
  32. will never run on their Mac Plus anyway". So I am asking, what can we learn
  33. from this experience, and what can be abstracted out for reuse by future
  34. MacAppers.
  35.  
  36. Larry,
  37.  
  38.     I agree with you and Edmund that virtual objects and persistent objects are
  39. independent capabilities. But when you have both they do interact, and can
  40. share some of the same mechanisms, so I have found it useful to implement them
  41. together. In my last implementation objects could be virtual, persistent, both,
  42. or neither, without anyone using the objects needing to know which was which.
  43.     The reason to include field type information with the metadata is so that
  44. applications can deal in limited ways with data whose classes they know nothing
  45. about. For instance, I can imagine an object compression/decompression utility
  46. that could use the field type data to choose its algorithms without needing to
  47. be linked to any of the methods for the classes in the data.
  48.     I still think metadata belongs in the resource fork: partly because it just
  49. seems more like a resource to me (in line with Ken's and Edmund's comparisons
  50. to TView), but mostly because the resource manager would make it trivial to
  51. connect class names, ids, and field type data. I hate to solve problems that
  52. have been already solved in ROM. I don't know anything about System 7 IPC, but
  53. it doesn't sound that hard to send the metadata resources separately from the
  54. data.
  55.  
  56. Metadata discussants,
  57.  
  58.     Cleary, life will be easier when Object Pascal gives us more metadata (try
  59. it as a chant: Give me an M…). But we waited years for 3.1, so we need to find
  60. solutions that work now. I still think that the Fields methods could be used as
  61. part of a default I/O system, along the lines Edmund and Geoff suggest, while
  62. retaining the flexibilty that Larry rightly insists on. I am less convinced
  63. that the information in .SYM files could be so used, although I could imagine a
  64. shell script that read through a .SYM file and automatically wrote all the
  65. Fields methods. Perhaps one of our shell experts is up to this one.
  66.  
  67. Yours truly,
  68.  
  69. Greg Colvin
  70.  
  71.  
  72.